Skip to content

Conversation

@Sg312
Copy link
Contributor

@Sg312 Sg312 commented Jan 10, 2026

Summary

Fix bugs with router (edge deletion, prompting)

Type of Change

  • Bug fix

Testing

Manual

Checklist

  • Code follows project style guidelines
  • Self-reviewed my changes
  • Tests added/updated and passing
  • No new warnings introduced
  • I confirm that I have read and agree to the terms outlined in the Contributor License Agreement (CLA)

@vercel
Copy link

vercel bot commented Jan 10, 2026

The latest updates on your projects. Learn more about Vercel for GitHub.

Project Deployment Review Updated (UTC)
docs Ready Ready Preview, Comment Jan 10, 2026 7:12pm

@greptile-apps
Copy link
Contributor

greptile-apps bot commented Jan 10, 2026

Greptile Overview

Greptile Summary

This PR attempts to fix router edge deletion and improve router prompting, but introduces a critical bug in route ID generation that will break workflow execution.

What Changed

The PR makes 4 main changes to the router v2 block:

  1. Edge deletion fix (condition-input.tsx): Now properly removes edges when deleting router routes using the router-${id} handle prefix
  2. Route ID fallback fix (workflow-block.tsx): Corrected fallback route ID from route-route1 to route1
  3. Autoconnect support (workflow.tsx): Added router_v2 to autoconnect logic to automatically connect new blocks
  4. Prompt improvements (router.ts): Made the system prompt more forceful to ensure LLM always returns a route ID
  5. Fallback behavior (router-handler.ts): Added fallback to first route instead of throwing error when LLM returns invalid route ID

Critical Issue Found

Route ID generation inconsistency in condition-input.tsx (line 627-632):

  • Default route uses: generateStableId(blockId, 'route1') → produces blockId-route1
  • New routes use: generateStableId(blockId, 'route-${Date.now()}') → produces blockId-route-1234567890
  • Expected format: blockId-route2, blockId-route3, etc.

This breaks the entire routing system because:

  • Handles are created with these IDs: router-${route.id}
  • Executor looks for handles matching router-${chosenRoute.id}
  • Mismatched formats mean connections won't be found and workflow execution will fail

Additional Concern

The silent fallback in router-handler.ts masks routing failures. While it prevents crashes, users won't know when the router isn't working properly, making debugging difficult.

Recommendation

DO NOT MERGE until the route ID generation bug is fixed. The edge deletion and autoconnect fixes are good, but the ID generation issue will cause runtime failures.

Confidence Score: 1/5

  • This PR contains a critical bug that will break router workflow execution
  • Score of 1 reflects the critical route ID generation bug in condition-input.tsx that creates inconsistent ID formats. This will cause edge matching failures and break workflow execution. While other changes are correct, this single issue makes the PR unsafe to merge.
  • Pay immediate attention to condition-input.tsx line 627 - the route ID generation must be fixed before merging

Important Files Changed

File Analysis

Filename Score Overview
apps/sim/app/workspace/[workspaceId]/w/[workflowId]/components/panel/components/editor/components/sub-block/components/condition-input/condition-input.tsx 2/5 Fixed edge deletion logic for router mode, but introduced critical bug in route ID generation that causes inconsistent IDs (route-${timestamp} vs route1, route2). This will break edge matching and workflow execution.
apps/sim/app/workspace/[workspaceId]/w/[workflowId]/components/workflow-block/workflow-block.tsx 5/5 Correctly fixed route ID fallback format from route-route1 to route1, matching the expected pattern. Changes are minimal and correct.
apps/sim/app/workspace/[workspaceId]/w/[workflowId]/workflow.tsx 5/5 Added router_v2 autoconnect support by querying for router handles. Implementation matches the pattern used for condition blocks and is correct.
apps/sim/blocks/blocks/router.ts 4/5 Updated router v2 prompt to be more forceful and deterministic. The aggressive language should improve LLM compliance, though effectiveness depends on actual LLM behavior.
apps/sim/executor/handlers/router/router-handler.ts 3/5 Added fallback to first route when LLM returns invalid ID. While this prevents crashes, it silently masks routing failures and could hide systemic issues. Consider adding metrics/tracking.

Sequence Diagram

sequenceDiagram
    participant User
    participant ConditionInput
    participant WorkflowBlock
    participant WorkflowCanvas
    participant RouterHandler
    participant EdgeManager

    Note over User,EdgeManager: Router Port Creation & Connection Flow

    User->>ConditionInput: Add new route
    ConditionInput->>ConditionInput: Generate route ID (BUG: uses timestamp)
    ConditionInput->>ConditionInput: Save route with ID "blockId-route-123456789"
    
    WorkflowBlock->>WorkflowBlock: Parse routes from JSON
    WorkflowBlock->>WorkflowBlock: Create handle with id="router-blockId-route-123456789"
    
    User->>WorkflowCanvas: Drag connection from router port
    WorkflowCanvas->>WorkflowCanvas: Auto-detect router handle
    WorkflowCanvas->>WorkflowCanvas: Create edge with sourceHandle="router-blockId-route-123456789"
    
    Note over User,EdgeManager: Workflow Execution Flow
    
    User->>RouterHandler: Execute workflow
    RouterHandler->>RouterHandler: Call LLM with context + route descriptions
    RouterHandler->>RouterHandler: LLM returns route ID
    
    alt Valid route ID
        RouterHandler->>RouterHandler: Find route in parsed routes
        RouterHandler->>EdgeManager: Look for edge with sourceHandle="router-{routeId}"
        EdgeManager->>EdgeManager: Match handle prefix "router-"
        EdgeManager->>RouterHandler: Return target block
        RouterHandler->>RouterHandler: Execute target block
    else Invalid route ID (NEW)
        RouterHandler->>RouterHandler: Log warning
        RouterHandler->>RouterHandler: Fallback to routes[0]
        Note right of RouterHandler: Silent failure - masks issues
        RouterHandler->>EdgeManager: Use first route ID
    end
    
    Note over User,EdgeManager: Edge Deletion Flow (FIXED)
    
    User->>ConditionInput: Delete route
    ConditionInput->>ConditionInput: Get route ID
    ConditionInput->>ConditionInput: Build handlePrefix "router-{routeId}"
    ConditionInput->>WorkflowCanvas: Remove edges matching prefix
    WorkflowCanvas->>WorkflowCanvas: Delete connected edges
Loading

Copy link
Contributor

@greptile-apps greptile-apps bot left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

2 files reviewed, 2 comments

Edit Code Review Agent Settings | Greptile

@greptile-apps
Copy link
Contributor

greptile-apps bot commented Jan 10, 2026

Additional Comments (1)

apps/sim/app/workspace/[workspaceId]/w/[workflowId]/components/panel/components/editor/components/sub-block/components/condition-input/condition-input.tsx
The route ID generation is inconsistent and will cause edge matching issues. The default route uses route1 (line 178: generateStableId(blockId, 'route1')), but new routes use route-${Date.now()} which creates a different format.

When workflow-block.tsx parses existing routes, it expects IDs in the format ${blockId}-route${index + 1} (line 867), which would be blockId-route1, blockId-route2, etc.

This inconsistency means:

  1. New routes created by the user will have IDs like blockId-route-1234567890, not blockId-route2
  2. Handles created for these routes won't match the expected pattern
  3. Edge connections and execution flow will break

Fix: Generate sequential route numbers instead of timestamps:

    // Count existing routes to determine next route number
    const routeCount = conditionalBlocks.filter(b => b.title.startsWith('route')).length
    const newBlockId = isRouterMode
      ? generateStableId(blockId, `route${routeCount + 1}`)
      : generateStableId(blockId, `else-if-${Date.now()}`)

    const newBlock: ConditionalBlock = {
      id: newBlockId,
      title: isRouterMode ? `route${routeCount + 1}` : '',
Prompt To Fix With AI
This is a comment left during a code review.
Path: apps/sim/app/workspace/[workspaceId]/w/[workflowId]/components/panel/components/editor/components/sub-block/components/condition-input/condition-input.tsx
Line: 627:632

Comment:
The route ID generation is inconsistent and will cause edge matching issues. The default route uses `route1` (line 178: `generateStableId(blockId, 'route1')`), but new routes use `route-${Date.now()}` which creates a different format.

When workflow-block.tsx parses existing routes, it expects IDs in the format `${blockId}-route${index + 1}` (line 867), which would be `blockId-route1`, `blockId-route2`, etc.

This inconsistency means:
1. New routes created by the user will have IDs like `blockId-route-1234567890`, not `blockId-route2`
2. Handles created for these routes won't match the expected pattern
3. Edge connections and execution flow will break

**Fix**: Generate sequential route numbers instead of timestamps:

```suggestion
    // Count existing routes to determine next route number
    const routeCount = conditionalBlocks.filter(b => b.title.startsWith('route')).length
    const newBlockId = isRouterMode
      ? generateStableId(blockId, `route${routeCount + 1}`)
      : generateStableId(blockId, `else-if-${Date.now()}`)

    const newBlock: ConditionalBlock = {
      id: newBlockId,
      title: isRouterMode ? `route${routeCount + 1}` : '',
```

How can I resolve this? If you propose a fix, please make it concise.

@icecrasher321 icecrasher321 merged commit 3ed1775 into staging Jan 10, 2026
10 checks passed
@waleedlatif1 waleedlatif1 deleted the fix/router branch January 12, 2026 04:08
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants